nao use isso pra passar 'segredos' já que os valores podem ser acessados usando docker history

ˢᶦⁿᵗᵃˣᵉ ↴

ARG <name>[=<default value>]

ᵉˣᵉᵐᵖˡᵒ ↴

ARG version
ARG user_name=admin

como se usaria:

$ docker build --build-arg version=1.0 -t <nome_img> .

$ docker build --build-arg version=1.1 \
               --build-arg user_name=joao \
               -t <nome_img> .

nao use ENV caso so precise do valor em build-time

ˢᶦⁿᵗᵃˣᵉ ↴

ENV <key>=<value> ...
ENV <key> <value> # com essa sintaxe, apenas um por linha

ᵉˣᵉᵐᵖˡᵒ ↴

ENV NODE_ENV="development"

ENV POSTGRES_USER="username" \
    POSTGRES_PASSWORD="password" \

ARG build_value
ENV run_value=$build_value

como se usaria:

# cenario 1
$ docker run --env NODE_ENV=production <nome_img>


# cenario 2
$ docker build --build-arg build_value=5 -t <nome_img> .

$ docker run -e run_value=8 <nome_img>

ˢᶦⁿᵗᵃˣᵉ ↴

FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]

ᵉˣᵉᵐᵖˡᵒˢ ↴

FROM node:14-alpine

FROM public.ecr.aws/micahhausler/alpine:3.14.0

ARG architecture
FROM --platform=linux/${architecture} openjdk

ˢᶦⁿᵗᵃˣᵉ ↴

LABEL <key>=<value> <key>=<value> <key>=<value> ...

ᵉˣᵉᵐᵖˡᵒ ↴

LABEL aleatorio.nome="valor1"
LABEL aleatorio.data="valor2"
LABEL chave1="c1" chave2="c2" \
      chave3="c3"

ˢᶦⁿᵗᵃˣᵉ ↴

WORKDIR /path/to/workdir

ᵉˣᵉᵐᵖˡᵒ ↴

WORKDIR /pasta1
WORKDIR /pasta2
WORKDIR pasta3

o resultado seria:

.
├── pasta1
└── pasta2
         └── pasta3 <diretorio atual>

o usuário tem que ser criado por você previamente no dockerfile

ˢᶦⁿᵗᵃˣᵉ ↴

USER <user>[:<group>]

ᵉˣᵉᵐᵖˡᵒ ↴

RUN groupadd -r grupo \
 && useradd usuario --groups grupo

USER usuario
USER usuario:grupo

copia arquivos/diretorios do Host (em relação ao contexto da build) para o Container (em relação ao WORKDIR)

pode-se utilizar wildcards nos caminhos advindos do host:

• * da match em qualquer sequencia de chars que não sejam separador (/, ou \ no windows)
• ? o mesmo, mas pra 1 char só

--chown não funciona no windows
não é mt recomendado o uso disso, já que o usuario só precisa de permissão pra executar, e não o ~domínio/ownership

para efeito de comparação/entendimento:

• exemplo com a flag chown
• exemplo sem chown

ˢᶦⁿᵗᵃˣᵉ ↴

COPY [--chown=<user>:<group>] <caminho_no_seu_pc>... <destino_no_container>
COPY [--chown=<user>:<group>] ["<caminho_no_seu_pc>",... "<destino_no_container>"]

A versão com [] é utilizada qnd se tem whitespace no path (ex: '/home/joao/minha pasta/')

ᵉˣᵉᵐᵖˡᵒ ↴

COPY minha_pasta/ /tmp/my_folder
COPY ["package*.json", "yarn.lock", "/meu_app/"]
COPY . .

O mesmo que o COPY, mas:

1. a fonte pode ser uma URL também (não recomendado, melhor usar RUN curl ou RUN wget etc)
2. auto-extrai arquivos .tar

Mais sobre as diferenças aqui.

ˢᶦⁿᵗᵃˣᵉ ↴

ADD [--chown=<user>:<group>] <src>... <dest>
ADD [--chown=<user>:<group>] ["<src>",... "<dest>"]

ᵉˣᵉᵐᵖˡᵒ ↴

ADD hom* /mydir/
ADD rootfs.tar.xz /
ADD https://example.com/music.mp3 /usr/src/things/

Provê algum padrão pro container em execução

só pode um CMD por dockerfile (caso tenham multiplos apenas o ultimo é considerado)

o formato exec não invoca um shell (a nao ser que especifique [ex: CMD ["sh", "-c", "echo $HOME"] ])

justamente por isso, CMD [ "echo", "$HOME" ] não teria o resultado esperado já que não há um shell pra processar/substituir a variavel

ˢᶦⁿᵗᵃˣᵉ ↴

# exec
CMD ["executable","param1","param2"]

# parametros pro ENTRYPOINT
CMD ["param1","param2"]

# shell
CMD command param1 param2

ᵉˣᵉᵐᵖˡᵒ ↴

CMD echo "This is a test."
CMD ["npm", "start"]

permite configurar um container pra ser rodado como um executavel

ˢᶦⁿᵗᵃˣᵉ ↴

# exec
ENTRYPOINT ["executable", "param1", "param2"]

# shell
ENTRYPOINT command param1 param2

ᵉˣᵉᵐᵖˡᵒ ↴

# exec
ENTRYPOINT ["top", "-b"]
CMD ["-c"]

# shell
ENTRYPOINT exec top -b

COPY package*.json .

RUN npm install

COPY . .

COPY . .

RUN npm install